One general remark: I prefer getters for fields which are set once (internally) and then shouldn't be possible to modify its value from outside (hence the "getter" and a private/unexported field). But this is more a question of style I guess.
And from from skimming through the code it looks like you carefully thought about which fields should be exported and which not.

Golang code should not use getters and setters rather than struct fields.

I think I know what you mean but in general this isn't always the case: In golang it isn't uncommon to have getters but they just aren't prefixed with get* (https://golang.org/doc/effective_go.html#Getters).

And from from skimming through the code it looks like you carefully thought about which fields should be exported and which not.

I think using getters for those fields have not much advantages compare to exporting them. If I use getters, I have to keep adding them whenever there are some new fields in struct, and I ain't sure it's good thing.

I think using getters for those fields have not much advantages compare to exporting them. If I use getters, I have to keep adding them whenever there are some new fields in struct, and I ain't sure it's good thing.

I agree that issues can arise from forgetting to add getters whenever you add a new struct field, but I don't see how it's a bad thing to have to add these getters. I agree with @liamsi and I think using getters where needed more properly expresses the access we want outside modules to have to certain fields. Exporting gives write-access to those fields, too, no? I'd rather take a more conservative approach and export only those fields that really need to be writable from outside.

Exporting gives write-access to those fields, too, no?

Yes, it does. I also agree with @liamsi , that's exactly why I use those getters at first.
However, some current getters return slice which is just a reference to underlying to an array and I can use returned slice to make changes to the original values. To make it truly read-only, I think I would return a copy of them instead. That's reason why I want to make these changes.
And except the STR, I think the other changes don't have much problems since changing its fields (in case the developers misused) doesn't break the tree or the hash chain, right?
Hopefully it makes thing more clear.

You are right, the getters do not prevent changing the underlying slices. I still think that those getters provided a nicer API, but now that you mentioned it, I agree that the getters seem to be even more misleading (as they provide a false sense of security and people coming from other languages might think they are not changing the underlying slices while in fact they are).

You convinced me and I'm OK with removing all those getters!

Thanks @c633 and @liamsi for the explanations!

some current getters return slice which is just a reference to underlying to an array and I can use returned slice to make changes to the original values. To make it truly read-only, I think I would return a copy of them instead. That's reason why I want to make these changes.

I see, it's a lot clearer to me now.

I agree that the getters seem to be even more misleading (as they provide a false sense of security and people coming from other languages might think they are not changing the underlying slices while in fact they are).

Yup, that's me. Coming from Java where getters are everywhere, I assumed they had the same semantics in Go.

LGTM.